Since many data processing applications involve highly confidential and business critical information (for example national security applications, financial applications), computer resource security is of utmost importance. In addition to physical controls (such as building security locks) and procedural controls (such as changing passwords), logical controls such as access authorization control, authentication (checking that a user is who they say they are) and cryptographic techniques are important. Where large numbers of user terminals are interconnected in a distributed processing network, with storage devices and data files stored throughout the network commonly being accessible from a plurality of terminals, the provision of effective security is a significant technical problem.
Modern computers are sold with operating system software installed therein for controlling the execution of programs and providing basic services such as resource allocation, scheduling, input and output control, and data management. A "resource" may be any facility or element of a computing system or operating system required by a task (for example storage, input/output devices, processing units, printers, data sets, files, or programs). Many operating systems, such as IBM's MVS/ESA and OS/400 operating systems, additionally provide comprehensive facilities for defining and managing system security (e.g. MVS/ESA has the RACF facility). (IBM, MVS/ESA, OS/400 and RACF are trademarks of International Business Machines Corporation). In particular, such operating systems provide facilities for defining the access authorizations which particular subjects have in relation to specific system resources. Subjects are the active components in a network, such as processes, users or groups of users. The subjects are said to be authorised to perform certain operations, or to have particular "capabilities" or "permissions" with respect to a resource. As an example, a subject may be authorised to update a specific file.
However, not all operating systems provide security facilities of such sophistication, or even any security. In particular, the technical problem of providing effective and comprehensive security is compounded in open distributed systems since the "open" operating systems themselves generally have only limited security facilities built into them, and because of complexities which are not encountered with centralised networks. For example, a security system for a distributed network must have the ability for a user to authorize a computer to operate on the user's behalf and only to do so while authorised.
An open distributed processing environment is described in "Security Architecture for Open Distributed Systems", S. Muftic et al, Wiley, 1993, as one in which computer systems with diverse applications, resources, users, and locations exchange and process various types of data and interact without any previous strict arrangements. An open systems platform is the term given to systems developed for such an environment comprising computer system hardware and the associated operating system software which it runs. The UNIX operating system developed by Unix System Laboratories and IBM's AIX operating system are examples of open operating systems (AIX is a trademark of International Business Machines Corporation and UNIX is a trademark licensed through X/Open Company Limited). Computer networks constructed within such an open environment generally have less sophisticated security provision than networks of computers running operating systems such as the OS/400 operating system. Typically, application programs which are run on open systems platforms are restricted to very basic authorization mechanisms if they are used at all. The increasing importance of open systems solutions for commercial data processing and inter-enterprise computer networking has increased the need for improved protection of users, resources and assets in open computer networks.
For example, the file system authorization facilities provided by the UNIX operating system comprise only the following three basic permissions per file:
READ Subject can view the contents of a file;
WRITE Subject can modify the contents of a file;
EXECUTE Subject can execute the file (the file being a program or script).
Each permission is represented by a one bit field. The permissions are defined to enable three categories of subject or user to be distinguished, one set of bits being defined in each case. The first category is the owner of the file, the second is any user in the group of users associated with the file, and the final category is every other user. A file may be set up, for example, as readable and writable by its owner, readable by the group, and inaccessible to any other user.
The permissions on directories are similarly simple, differing slightly from the permissions on files, as follows:
READ User can list the directory;
WRITE User can create or delete files in this directory;
EXECUTE User can search the contents of the directory and make it the current directory.
This level of granularity of authorization clearly has very little flexibility and is not sufficient for many purposes--the authorization access controls are not expressive enough to specify a comprehensive security policy and the fact that the security facilities only apply to files and directories is a severe limitation. For example, a company may wish to transfer an existing commercial application program which deals with sensitive information and which was written for one computer system onto an open system platform (referred to as "porting" the application to the open system) and yet to maintain the sophisticated security control which was available on the first system. The authorization permissions of the UNIX system are too coarse to permit this without additional authorization control services.
The fact that the UNIX operating system does not provide an effective mechanism for establishing a secure computer system has already been noted in the prior art, for example in EP-A-0325777 which describes a mechanism for an open distributed system for auditing information which must be securely protected so that actions affecting security may be traced to the responsible user. EP-A-0325777 thus relates mainly to detection and indication of security problems, rather than to mechanisms for prevention of computer resource misuse.
One solution for systems with limited security provision is to rely on security mechanisms being implemented by the applications which run on the system, appropriate security measures being built into the applications on an individual basis. However, there remain the problems that such security measures tend to be of limited scope and applicability and are usually incompatible in larger distributed systems. The drawbacks of providing security in each application on an individual basis are identified by Muftic et al in "Security Architecture for Open Distributed Systems", Wiley, 1993, as follows:
1. The integration and functional completeness of the overall security system in a broader operational environment may not be feasible;
2. It is difficult to analyze and evaluate the overall strength of such a global security system;
3. Implementation, and therefore usage, of individual security algorithms, mechanisms, and services may be duplicated, or interfere with one another;
4. It is not easy to define a formal description of the global security system, suitable for its rigorous analysis; and
5. It is very inconvenient to establish a common security architecture and policy for integration and optimisation of individual security services.
The above-mentioned book goes on to describe the authors' views on the desirable features, protocols, services and mechanisms of a comprehensive security system architecture--i.e. setting out proposals for an architecture rather than methods of implementing flexible resource security using the existing security facilities of open distributed systems.
Other prior art systems have sought to provide additional preventative security mechanisms on top of the basic facilities of the operating system. EP-A-0561569 discloses restricting user access to a protected resource by requiring a call to a user monitor command, specifying the protected resource as a parameter, the user monitor command then checking that predetermined conditions are satisfied before permitting access to the protected resource.
U.S. Pat. No. 5,173,939 describes a basic access control model in which a reference monitor examines requests for access to particular system resources and decides whether to grant that access based on the resource, who the request is from, the resource operation specified in the request, and definitions of which users are listed as being authorised to perform the requested operation. U.S. Pat. No. 5,173,939 discloses attaching to particular objects or resources an access control list (ACL) which is a list specifying which users are authorised to perform a specific operation, seeking to minimize the information which must be retained in the ACL by defining a hierarchy of levels of authorization (i.e. if one entity is authorised to perform an operation then all entities having a higher authorization level are also authorised and so need not be listed in the ACL). Despite the reduction of information stored in the ACL's, such a system of storing authorization lists in association with system resources has an undesirable maintenance overhead. The problem of the inflexibility of security provision in open distributed systems is not addressed.
U.S. Pat. No. 5,220,604 discloses an authorization level hierarchy and a method for excluding certain groups from resource access. U.S. Pat. No. 5,220,604 describes the resources of the distributed computer system implementing their own security policy, the resource itself determining the access rights of a user when the user requests resource access and then the resource deciding whether to allow or reject the request. This is distinguished from the centrally managed resource access determinations which are typical in non-distributed systems. Systems such as described in U.S. Pat. No. 5,220,604 often rely on users being assigned user names, with access to resources being on the basis of the access rights known to be associated with a particular user name. This may be implemented by each system resource including a listing of all users and their access rights and user names, but the overhead of maintaining and updating all of the access control lists is considerable if numerous system resources exist and so this solution is often impractical. Alternatively, there may be a central list accessible to all resources of the network, with a global naming service providing user name resolution. In the invention of U.S. Pat. No. 5,220,604, an access control list provided for each system resource lists all possible access privileges and the users that have these privileges. When a user requests access to a resource, the user's name is compared to the resource's access control list; if the name is on the list then access will be granted. U.S. Pat. No. 5,220,604 provides no solution to the specific problem of the inflexibility or non-granularity of the authorization facilities which are available on open distributed systems.